Subject: Capabilities Summary (First Pass)

From: [email-masked]
Date: Fri, 23 Jul 93 09:09:34 PDT

To all -

    I've attached the first attempt at summarizing all of the email over the
    past 2 weeks.  Please look it over and let me know (either privately
    or in the group) if I've gotten anything wrong.  It was harder than
    I thought.

    I'm open to alterative formats.  There was too much information to
    include in a matrix so I settled on this format as a start.

    I will maintain the list and update it periodically like I did the
    original DLSw matrix (with regular postings to the mailgroup).

Thanks,
Wayne


			Capabilities DLSw SIGlet

			     Feature List

		    Fri Jul 23 08:25:23 PDT 1993

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	Base Set vs. Option Sets
    Description:	What features in DLSw should be base requirements for
			interoperability and which ones should be optional.
    Member Input:
	Cayman		Base = tunnel creation, capability exchg, receive all
			packets w/o dying, flow control
	Novell		NetBIOS support is optional.
	Eicon		Base set implied by today's DLSw (i.e. default
			capabilities).
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	Vendor Id
    Description:	Include a vendor id, vendor release number, etc. in
			the capabilities exchange.
    Member Input:
	Cisco		Vendor id is a good thing.
	Wellfleet	Wary about vendor id.
	Proteon		Vendor id is a good thing.  Aids in problem det.
	Cayman		Don't like vendor id.  Invites variations.
	Hypercom	Vendor id is a good thing.  Aids in problem det.
	Novell		Vendor id is a good thing.  Good for troubleshooting.
	Eicon		Vendor id is a good thing.  Ignoring it is ok.
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	TCP vs. UDP for Capabilities Exchange
    Description:	Transport of the capabilities across TCP or UDP.
    Member Input:
	Cisco		TCP or UDP, with a preference for UDP.
	Novell		TCP only.  For reasons of alternate transport.
	BBN		TCP only.  For reasons of alternate transport.
	Wellfleet	TCP only.  Use another SSP message within TCP.
	Cayman		TCP only.  Use another SSP message within TCP.
	Hypercom	Leaning toward UDP.
	Ascom/T-plex	TCP only.  Use another SSP message within TCP.
			Concerned about requiring IP multicast.
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	Data Stream Format
    Description:	How should the capabilities exchange data stream
			be formatted?
    Member Input:
	Cisco		GDS format (i.e. LLID).
	Novell		Reserved bytes in message header.
	Cayman		Tag / length. (i.e. like GDS = editor note)
	Hypercom	GDS format (i.e. LLID).
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	Optional CANUREACH / ICANREACH
    Description:	Should CUR/ICR be optional at connection startup?
    Member Input:
	Cisco		They should be optional.  Must be able to send/recv.
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Feature:	Directory Server / Name Server
    Description:	How should DLSw-capable routers find out about each
			other?
    Member Input:
	Radlinx		List of already-known DLSw routers in capabilities
			exchange.
	Hypercom	Name server treading onto APPN turf. Objective, but
			not in the base.
	Cisco		List of already-known DLSw routers in capabilities
			exchange.
	Novell		List of DLSw routers in capabilities exchange.  Don't
			want it link state-based.
	Eicon		Wants a directory server. DS capability in exchange.
    Comments:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: [email-masked] (David Matusow)
Date: Fri, 23 Jul 93 15:41:33 -0400

Just some clarification of our position on name server.

We believe that a name server is a very feasible and good objective.
Our concern was to pass configuration data on other DLS routers on
contact.  This passing of directory information is NOT, we feel, a
good direction for DLS.  It leads to a potentially large amount of
info being continually passed around the network (update requirements
are always there, so let's be honest and know that people will want
reasonably up-to-date information).

A name server, on the other hand, is the correct method of providing
this service.  Let one node be configured and designed to provide this
service and not overload the routers themselves.

if the exchange of directory is included, it should be obviously built
as a capability and not a base function.  The requirement of passing
data to a name server or designing a method of this node learning about
the network configuration, including the precence of DLS routers, is
something that we would be very open and involved in.

David Matusow
Hypercom

---

From: Choon Lee <[email-masked]>
Date: Fri, 23 Jul 1993 12:59:07 -0700

I would like to add another option set to the list, namely the ability to
participate in a yet-to-be-defined loop prevention protocol.

Regards,

Choon Lee
3Com Corp.

---

From: Gilbert Moineau <[email-masked]>
Date: Mon, 26 Jul 93 15:21:00 PDT

Wayne,

Just two mistakes about Eicon positions:

1- We want to use only TCP for capabilities exchange

2- We think a Directory Service could be a good idea, but, we should not 
address this problem in this
     group, now. It is a feature, not a negotiation issue.

                              Gilbert Moineau,  Eicon Technology